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The present invention relates to the field of mobile 
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computing solutions . A particular embodiment relates to 
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a fully customisable system and software means for co- 
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of mobile workers. 
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At the present time, many industries provide mobile 




10 


workers with mobile computing and communication devices 
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which are used to provide the mobile worker with 
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information they need to carry out their job, and also to 
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store information reporting the tasks they have carried 
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out. Example mobile workers are meter readers, goods 
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delivery workers, travelling salesmen etc. Examples of 




16 


the type of information would be a list of things to do 
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during the day, customer addresses etc and then 
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confirmation and verification information that tasks had 
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been carried out, time stamps for particular events, new 
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client information, notes etc. 
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For example, a postal delivery worker might, on a daily 
basis , download a list of parcels to deliver, where and 
when they have to be delivered and may, in the course of 
deliveries, scan parcel bar codes or make records to show 
that deliveries have been completed at particular times. 
Typically, these systems require considerable hardware 
specific programming and implementation « Such systems 
need customised depending on the nature of the hardware 
devices carried by mobile workers, the servers organising 
the system and the networking hardware (e.g. ethernet, 
telephone network) use for interfacing with mobile units 
at the beginning and end of the day. As well as the time 
and expense involved in customisation this means that 
individual organisations have separate and non-compatible 
mobile computing solutions. 

Recently, internet-based application servers have become 
a popular method of delivering computing solutions to 
multiple users. It would be desirable to provide an 
application server adapted for the needs of companies 
with mobile workers. However, given the use by different 
firms of different hardware and software programs it is 
hard to see how this could be achieved and so an aim of 
the present invention is to provide application server 
technology for use in delivering mobile computing 
solutions to multiple users, being fully internet 
enabled, customisable and requiring minimal or no 
configuration by mobile workers. 

One aim of the present invention is to provide a system 
which can be operated using any type of commercially 
available mobile computing hardware without 
customisation. In the present system the only action 
typically required by a user to configure a mobile unit 
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for use with the system is to input one internet address 
once . 

A further aim of the present invention is to provide a 
means for enabling the system to function when individual 
mobile communication and computing devices are 
periodically on and off-line. In one extreme at the 
present time, mobile computing device have information 
downloaded into them once per day (e.g. a list of tasks) 
and uploaded to a central server at the end of the day. 
In another extreme it is known to provide a web server 
application which can be accessed online; however, this 
type of system cannot function when offline and, as it is 
prohibitively expensive to remain permanently connected, 
is not financially viable. 

Therefore, another aim of the present invention is to 
enable mobile workers to benefit from the communications 
possibilities of mobile network communications with a 
base system, whilst continuing to be able to function 
seamlessly when said mobile communications networks are 
unavailable . 

A further aim is to gain the benefits of dynamic 
communication with a remote server without the high costs 
of, for example, an always on internet connection. 

A further aim of the present invention is to provide a 
worker with access to the task and data information 
servers belonging to a plurality of third party 
organisations which have different hardware and software 
systems . 
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1 A yet further aim is to implement the above aims whilst 

2 requiring the mobile units to have only standard browser 

3 and communications software and hardware . 
4 

5 According to a first aspect of the present invention 

6 there is provided a system comprising: 
7 



8 a plurality of mobile units for use by mobile users; 
9 

10 an application server; 
11 

12 communications means for enabling said mobile units 

13 to communicate with the application server; 
14 

15 a subscriber database comprising information about 

16 the software and/or hardware capabilities of 

17 individual mobile units; 
18 

19 a script database comprising equivalent script 

20 segments for carrying out particular functions on 

21 mobile units with different software and/or hardware 

22 capabilities; wherein 
23 

24 the application server is adapted to provide an 

25 application script to a mobile unit, said 

26 application script being prepared from script 

27 segments selected from the script database according 

28 to the information about the mobile unit stored in 

29 the subscriber database. 
30 

31 Preferably, the system further comprises a master 

32 database, said master database having mobile user 

33 specific data, said application script further comprising 
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mobile user specific data specific to the mobile user 
acquired from the master database. 

Preferably, a mobile unit stores a copy of said mobile 
user specific data. 

More preferably, a mobile unit edits the copy of said 
mobile user specific data. 

Preferably also, the copy of said mobile user specific 
data is synchronised with the mobile user specific data 
stored in the master database. 

Most preferably, the application script is synchronised 
concomitantly with synchronisation of the mobile user 
specific data. 

Typically, the mobile user specific data relates to tasks 
carried out by said mobile user. 

Preferably mobile user specific data relates to tasks 
which have been or are being carried out by said mobile 
user . 

Preferably, the system further comprises master 
application program code means which are interpreted by 
the application server to prepare the application script. 

Most preferably, the master application program code 
means is stored in markup language. 

Said mobile units may communicate with the application 
server over the internet. 



6 

1 Said mobile units may comprise a browser, said browser 

2 executing the application script. 
3 

4 According to a second aspect of the present invention 

5 there is provided a method comprising the steps of: 
6 

7 acquiring information about the software and/or hardware 

8 capabilities of a mobile unit from a subscriber database, 

9 the mobile unit being for use by a mobile user; and 
10 

11 preparing an application script customised for the mobile 

12 unit from script segments being selected from a script 

13 segment database according to the software and/or 

14 hardware capabilities of the mobile unit. 
15 

16 Preferably, said application script further comprises 

17 data specific to a mobile user acquired from a master 

18 database of mobile user specific data. 
19 

20 Preferably also, a mobile unit stores a copy of said data 

21 specific to a mobile user. 
22 

23 Preferably, the copy of the data specific to a mobile 

24 user is edited by the mobile user. 
25 

26 More preferably, the method further comprises the step of 

27 synchronising the copy of the data specific to a mobile 

28 user with the data specific to a mobile user stored in 

29 the master database. 
30 

31 Preferably, said data specific to a mobile user comprises 

32 information concerning tasks to be performed by or which 

33 have been performed by said mobile user. 
34 
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Preferably, said application script is prepared with 
reference to a master application. 

Typically, said master application is stored in the form 
of a markup language . 

A mobile unit may comprise a browser and the application 
script be executed by said browser. 

According to a third aspect of the present invention 
there is provided a computer program comprising program 
instructions which, when loaded into a computer, comprise 
the application server of the system of the first aspect. 

According to a fourth aspect of the present invention 
there is provided a computer program comprising program 
instructions for causing a computer to perform the 
process of any of the second aspect. 

According to a fifth aspect of the present invention 
there is provided a computer program comprising the 
application script of any of the second aspect. 

The present invention will now be illustrated with 
reference to the following figures in which: 

Figure 1 shows a schematic diagram of overall system 
architecture; 

Figure 2 shows a flow chart of a typical days 
operations by a mobile worker; 
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1 

2 Figure 3 shows a block diagram of components of a 

3 mobile device according to the present invention. 
4 

5 
6 
7 

8 System overview 
9 

10 Figure 1 illustrates in block format the individual 

11 components of the system and the connectivity between 

12 them. The system comprises a web application server 100, 

13 and a plurality of mobile computing devices capable of 

14 executing scripts shown by way of example as 201 - 204 

15 and referred to generally as 200. Typically, there are 

16 further provided one or more information servers shown by 

17 way of example as 451 - 453 and referred to generally as 

18 450. 
19 

20 The invention comprises program code, usually localised 

21 on the web application server, to enable different mobile 

22 units to function with the web application server. The 

23 invention also comprises one or more applications in a 

24 mark-up language, referred to below as mobile application 

25 mark-up language (MAML) , and the overall methodology and 

26 hardware of the system as a whole. MAML Applications 

27 dictate mobile device functionality and, in two different 

28 embodiments are either (a) interpreted into a script 

29 language appropriate to an individual mobile unit with 

30 reference to a database 150 of subscriber mobile unit 

31 information or (b) transmitted in MAML to the mobile 

32 computing devices which have thereon MAML interpreters. 
33 
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1 The invention also comprises a further protocol using 

2 markup language, here termed Application Extensible 

3 Mobile Language (AXML) used for exchange of information 

4 between the web application server and information 

5 servers. 
6 

7 The mobile devices 200 for use with the system can be of 

8 a variety of different types. The requirements of each 

9 are that it can communicate with the web application 

10 server, downloading and executing scripts and having the 

11 capacity to upload data. 
12 

13 Mobile device hardware/software 
14 

15 Example mobile devices 200 would be a Windows CE™ mobile 

16 device 201 with JavaScript™ enabled browser 211, a WAP 

17 mobile device 202 with WMLScript™ 212 connected through a 

18 WAP server 222, a KVM™ mobile device 203 or Java™ virtual 

19 machine. Future technologies such as iMode™ and other 

20 formats could clearly also be used. In another 

21 embodiment an uninterpreted Application in the 

22 proprietary format herein referred to as MAML, discussed 

23 below can be interpreted by a MAML enabled mobile device 

24 204. Essentially, each mobile device 200 requires the 

25 capacity to exchange information with the web application 

26 server 100, execute a script and input/output date 

27 through a user interface. 
28 

29 Browsers may be supplemented by ActiveX™ components or 

30 Java™ Applets on the device to communicate with device 

31 specific interfaces 220 for driving peripherals 221, for 

32 example, software and hardware interfaces for signature 

33 capture systems, scanners, printers, the global 

34 positioning system, mobile telephone locating systems 
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etc. This means that the mobile device can be used more 
or less out of the box with no specific applications or 
data required. 

Mobile devices may for example be in the form of mobile 
telephones, palmtop organisers , laptop computers, 
computers integrated into vehicles etc. Users of mobile 
devices will typically be travelling workers such as 
salesmen, meter readers, delivery workers, van drivers, 
factory workers or robots. 

In the example embodiment, mobile devices 200 communicate 
with the central web application server 100 via a network 
server 125, typically an HTTP server, using TCP/IP. 
Communication between server 125 and mobile units 200 is 
through a communications network 300. The communications 
network 300 could be a fixed PSTN line, LAN or WAN into 
which mobile units 200 can be connected from time to 
time, but will preferably be a mobile communications 
network such as GSM, GPRS or future mobile telephone 
systems. The mobile device could also be connected to 
either an Intranet or an Internet via a standard RAS 
connection using a direct network connection. 
Information is exchanged between the network server 125 
and mobile units 200 using known hardware independent 
exchange protocols such as TCP/IP. Use of a standard 
protocol such as TCP/IP allows different physical 
communications 300 to be readily used with different 
mobile devices 200. Different types of physical 
communications network can be integrated as alternatives 
or consecutively as a data transmission pathway. 

Application server hardware/software 
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1 The web application server can be implemented in an 

2 industry standard development environment and application 

3 server for example COLDFUSION™ o Usefully COLDFUSION™ can 

4 be run on any platform such as Windows NT™, SOLARIS™, 

5 LINUX™. The HTTP servers can be implemented using, for 

6 example, APACHE™, or other similar servers. 
7 

8 The web application server 100 has access to a subscriber 

9 database 150 which comprises information about the 

10 hardware and software capabilities, configuration and 

11 user data relating to individual subscriber mobile 

12 devices showing generally as 200. The subscriber 

13 database is describe further below. Typically, the 

14 subscriber database is directly connected to the web 

15 application server 100; alternatively, information can be 

16 stored on information servers or MAML enabled mobile 

17 devices 204. 
18 

19 Information server hardware/software 
20 

21 Information server systems comprise typically, an HTTP 

22 server 400, an information server. Native or ODBC 

23 drivers 470 may be used to interface between an server 

24 451 and associated database 460. Said databases and 

25 drivers are readily implemented using common software 

26 tools available from, for example, Sybase™, Oracle™, 

27 DB2™, SQL server™ etc. Commonly available information 

28 servers include those sold by VANMAN™, OPTRAC™ and 

29 Systems Union™. 
30 

31 Typically, the central web application server 100 is 

32 connected through the internet to one or more information 

33 server systems shown by way of example as 451, 452 and 

34 453 and referred to generally as 450. The information 
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1 servers 450 may belong to the same organisation that owns 

2 the web application server 100 or may belong to third 

3 party organisations. Importantly, each of these 

4 information server systems may be entirely different in 

5 internal composition and configuration. The only 

6 requirement is that they can communicate with the central 

7 web application server in a specified interface format 

8 discussed below. The information servers function to 

9 provide information required by users of mobile units and 

10 to store information returned by them. For example, an 

11 information server may comprise information about a list 

12 of tasks to be performed on a particular day by a 

13 particular mobile user, belonging to a particular 

14 organisation which has subscribed to the facility 

15 provided by the web application server 100. 



yt 

,m 16 



L I? Use of system by end user 

Hy 19 Figure 2 shows a flow chart of an example day's use of a 

!-5 20 mobile communications device and of the systems owned by 

HI 21 an individual travelling worker. An important is that 

22 the system as a whole can work with different mobile 

23 units without them requiring extensive personalisation. 

24 The aspect of the system which makes this possible is the 

25 ability of the web application server to store in the 

26 subscriber information database information about the 

27 individual mobile unit and the use of MAML/AXML described 

28 below to customise the script sent to the individual 

29 mobile unit. 
30 

31 To begin with 601, the mobile communications device 

32 connects across a network such as an Intranet or the 

33 Internet as discussed above to the central web 

34 application server 100. After connecting 602, the device 
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1 logs in 603 to an information server 450 or central web 

2 application server 100, for example, using TCP/IP. The 

3 mobile unit might log into a start page defined by a 

4 universal resource locator, for example it might connect 

5 to a web page belonging to a proprietor/user of an 

6 information server 450, preferably this will be the 

7 internet address of the web application server 100. 
8 

9 The mobile unit may be pre-set up for a particular user 

10 with password etc information. Alternatively, the web 

11 application server may use caller line identification, 
^ 12 cookies or other identification techniques to establish 
A 13 the user. The user is then either recognised or rejected 
^; 14 604. Upon log-in the system identifies the user 605 and 
rij 15 their device as this is part of the user set-up. The 

16 subscriber database 150 may contain further information 

i.ri 

!3 17 relating to the particular user of the mobile device, 

W 18 such as the type of device they are using, their 

fljj 19 location, the nature of their business, the type of third 

20 party application servers 450 to which they should be 

flj 21 allowed access etc. A document is then downloaded 606 

22 from the central web application server and third party 

23 application servers 415. The particular information 

24 downloaded is based on information held in the central 

25 subscriber database 150 and task information stored in 

26 third parties databases and servers 450 460. 
27 

28 These can be managed directly from the depot which 

29 controls individual projects. For example, it will 

30 prescribe a particular series of tasks such as locations 

31 we visited, parcels to be dropped off which has been 

32 decided by the depot. The information is downloaded in 

33 the form of a script comprising both an application and 

34 associated data. The script is customised for the 
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particular mobile unit and mobile worker, the application 
being adapted to function on their particular mobile unit 
and the data being customised to a particular list of 
tasks. This customisation is described further below. 

At some point after recognition 605 and typically after 
download or concurrently with download 606, the mobile 
unit 200 will in some embodiments be locked 607 to 
prevent access to other functionality. This enables the 
complete functionality of the hand-held unit to be 
prescribed, although, for example, a restricted option 
password may be provided to allow a return to full 
operating system functionality . The access to other 
mobile device functionality whilst the programme is 
running may be varied depending on information held on 
the subscriber database 150 about the nature of the user 
and their level of technical sophistication. Locking is 
not essential but will be preferred for some users. 

Next, the user will perform their day's work 608. For 
example, they will be able to print information such as 
receipts, print-outs of job tasks etc., look at lists of 
tasks and associated information. They will be able to 
read bar code information, read/write to intelligent tags 
etc. They may be able to capture signatures and other 
identifying material and transmit these back to base. A 
benefit of the invention is that instead of them having 
to perform this upload only at the end of the day or only 
on-line every time they carry out a transaction, data and 
application synchronisation can be performed at 
intervals. Furthermore, they will be able to read credit 
cards /smart card information, handle complex transaction 
information such as calculating pricing costs etc off- 
line and will be able to communicate with other devices 
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1 such as vehicle black boxes, GPS etc 218. Importantly, 

2 interface design will be simple and easy to use, 
3 

4 At any point during the day the user will be able to 

5 synchronise 609 / transmit / download information from 

6 the Web application server 100 and information servers. 

7 For example, they would be able to transmit information 

8 of work that has been completed such as parcels picked up 

9 or delivered, and pick up information about new work. As 

10 well as just exchanging and synchronising data, the 

11 system is also capable of exchanging and synchronising 

12 the actual application software running on the mobile 

13 unit. Therefore they can readily download updates to 

14 software. This feature might be particularly important 

15 when they wish to deal with several different third party 

16 information services 451, 452 and 453 for which different 

17 software will be required. 
18 

19 The term "synchronise" refers to the known process of 

20 making two different data sets, such as lists of tasks, 

21 correspond in meaning. Typically, the list of tasks in 

22 the mobile unit is synchronised with the list of tasks 

23 stored in an information server 450 or associated 

24 database 460. For example, when the mobile unit has 

25 updated a record relating to a particular task, the 

26 synchronisation process would involve updating the record 

27 in the database 460 with that updated record. Rules can 

28 readily be written by one skilled in the art to deal with 

29 situations when both records may have changed. 

30 Application synchronisation involves ensuring that the 

31 application within the mobile unit is the version 

32 considered most appropriate by the web application server 

33 100. 
34 
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1 At the end of the day the user can then reconnect to the 

2 central web application server 100 and upload data 610 

3 concerning their tasks carried out during the day. At 

4 that point the day's tasks end 611 and information to do 

5 with one journey is finished and another journey can be 

6 begun immediately or at a later date. Although one day 

7 has been referred to as the duration of an individual 

8 journey in this application, it will be clear to one 

9 skilled in the art that this could be any period, for 

10 example, a few hours or a few days or weeks or even 

11 indefinitely. 
12 

13 The above operation routine is common to all potential 

14 use of the system, for example van sales, parcel 

15 delivery, fuel service etc. 
16 

17 Data formats 
18 

19 A variety of different information exchange formats are 

20 used between different components of the system and 

21 several of these are new and important to the 

22 functionality of the invention. Importantly, application 

23 and data information delivered to individual mobile units 

24 is in the form of script in standard mark-up language. 

25 Whereas the information delivered and the way in which it 

26 operates is new, the underlying software, being delivery 

27 of web documents through standard HTTP servers, is 

28 standard allowing integration with common known software 

29 and hardware implementations. HTTP is used as common 

30 protocol for communications and also allows the central 

31 web application server 100 to exchange information with 

32 other HTTP servers 400, database sources and other 

33 devices such as mobile telephones etc. 
34 
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As discussed above, each mobile device 200 has the 
capacity to execute a script and input/output data with a 
user. 

The central web application server 100 accepts, 
validates, authenticates and processes requests from the 
mobile units 200. Importantly, the central web 
application servers provides a subscriber database 150 to 
use in this process. This database contains information 
on the types of browsers , other software components, 
subscribers applications and any spoken language 
translations provided on individual mobile units. The 
information for the subscriber database can be imported 
from the information servers 450 or the information 
servers associated databases 460, or may be maintained 
standalone and connected directly to the web application 
server as shown in Figure 1, Alternatively, the 
subscriber database can be held in a plurality of 
locations . 

Once requests for information are received from the 
mobile unit and validated, script is then delivered by 
the central web application server 100 to the mobile unit 
200. Importantly, the central web application server 100 
obtains data and application information relevant to the 
user of the individual handheld unit 200, for example 
task lists, from the relevant HTTP information server 400 
in the form of a specialised version of XML, referred to 
herein as application extensible mark-up language, AXML. 

This data is then combined with application related 
information which is assembled in the form of mobile 
application mark-up language, MAML which is a format we 
have designed to enable the HTML/JavaScript capabilities 
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1 and mobile browsers (or in the case of WAP browsers, 

2 WML/WMLScript) to function with this system. MAML also 

3 allows the delivered application to continue running and 

4 being used without the browser being connected to the 

5 server. It also provides specific functions required on 

6 the individual mobile device 200 to make that application 

7 easy and fast to use. 
8 

9 Data flow, MAML interpretation 
10 

11 Figure 3 shows an example of the flow of data through the 

12 system. In this example, a mobile unit 200 sends an HTTP 
A 13 request to the web application server 100. In response 
^ 14 to this the web application server 100 makes a further 

rp 15 HTTP request to an information server 450 in AXML for 

^ 16 task data relating to the particular user of the mobile 

7 17 unit. 

:rf 18 

Hi 

fy 19 Task related data 701 is stored within a database 750 and 

Pi; 3 

20 in an example format contains header information 704 

21 relating to a particular individual 703 and a particular 

22 day 702. The database 750 can be stored on or associated 

23 with an information server or in any other location 

24 directly or indirectly accessible by the web application 

25 server 100. A list of tasks 705, 706 etc is also stored 

26 in an appropriate data format as will be clear to one 

27 skilled in the art. Example tasks might involve a 

28 particular action (deliver a parcel / meet a client / 

29 read a meter), identifier information (location for a 

30 delivery, identifier for a parcel, miscellaneous 

31 information data), time and location information. 
32 

33 Task data can be submitted to the system in numerous 

34 ways. For example, it could be held on task information 
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databases associated with third party information servers 
450 to enable easy interface with in-house systems. 
Alternatively, it could be submitted over the internet 
directly to a task information database associated with 
the web application server 100. For example, a worker at 
a factory requiring delivery of a product might use 
conventional web technology to submit a request to a web 
site associated with the tasks information databases for 
said particular product to be delivered. Information 
might also be supplied by mobile users, during the 
process of application and data synchronisation or as 
separate requests. 

In response to the request from the web application 
server 200, the task data record 701 is then processed by 
the information server 450 and transmitted to the central 
web application server 100 in the form of an AXML 
document 710. 

An Application 715 for interpretation and delivery to the 
mobile unit 200 is stored in MAML format, typically on 
the web server 100 although it can be supplied by 
information servers 450 or other sources. In order to 
prepare a script 740 to transmit to the mobile unit, the 
AXML document 710 and MAML Application 715 are required, 
along with two different further classes of data records: 
a subscriber database 720 and script database 730 are 
usually held within the subscriber database 150. The 
subscriber database 720 contains information concerning 
the particular user of a mobile unit 200 and the 
configuration and capabilities of that unit and 
peripherals associated therewith. The script database 
730 contains hardware and software specific segments of 
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1 script. Preferably, subscriber database and script 

2 database are both in the form of lists. 
3 

4 MAML is interpreted by the web application server 100 by 

5 sequentially selecting script segments from script 

6 database 730 as appropriate depending on the user 

7 information stored in the subscriber database 720. For 

8 example, the script segment data records will contain 

9 script for common functions e.g. displaying buttons, 

10 formatting frames, displaying text etc. in several 

11 different formats such as WML Script, JavaScript etc. and 

12 the appropriate script segment is selected depending on 

13 the type and capabilities of the machine as stored in the 

14 user information records 120. 
15 

16 Therefore a script 740 comprising an interpreted 

17 application is produced and combined with the data 

18 received in AXML format. This is then delivered to the 

19 mobile unit 200 where it is executed. As part of the 

20 execution process, the copy of the data on the mobile 

21 unit 200 can be viewed, amended, edited, deleted or added 

22 to. Importantly, this can be carried out whilst the 

23 mobile unit 200 is offline. 
24 

25 Whilst it runs offline the data contained within the 

26 script can be altered and records containing additional 

27 information, such as signatures, notes and timestamps 

28 relating to deliveries and events can be stored within 

29 for transmission back to the mobile web application 

30 server 100 the next time the mobile unit communicates 

31 with the web application server 100. 
32 

33 Periodically the mobile unit 200 can request 

34 synchronisation and the task data is synchronised with 
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that stored in the task database 460, being reconverted 
into AXML for transmission to information servers 450. 

As a result of this process, information for transmission 
to/from diverse information servers 450, can be 
integrated into a standardised form and exchanged with 
diverse mobile units 200. This allows the owners of the 
information servers 450 to concentrate on provision of 
the data being exchanged whereas the owners of the 
central web application server 100 can concentrate on the 
front end, user interface and, importantly, adaptation 
for different software and hardware configurations of 
mobile unit. 

XML data may be converted into different markup formats 
using the XML document transformation standard XSLT 
(Extensible Stylesheet Language Transformations) or 
similar transformation techniques. This may be required 
to enable particular information servers 450 to 
communicate with HTTP servers 400. 

The present invention has enabled mobile workers to use 
mobile units with regularly updated applications and 
information without requiring the costs of an always-on 
connection or the time limitations of only being able to 
download/upload information on a daily basis. 

Furthermore, the invention enables owners of information 
servers to maintain their databases without requiring 
them to additionally take on the complex role of 
providing access to their databases to mobile users who 
may have a plurality of different types of device. 
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This also enables a mobile user 100 to carry out tasks 
relating to multiple corporations as a single web 
application server 100 can interface with several 
information servers 450. 

As the invention relates to the overall configuration of 
the system and the functionality of the central web 
application server 100, information server 450 and 
associated databases 150, 460, standard mobile computing 
devices can be immediately used with the system with 
minimal or no customisation, providing a cost-effective 
solution. 

In another embodiment, the web application server 100 
functionality is fully integrated with an information 
server 450 and the relevant software may be provided as a 
module to add functionality to an information server 450. 

In further embodiments the information provided to mobile 
users need not be limited to task related information. 
The system will be useful wherever data can usefully be 
distributed to and received from mobile users using 
diverse mobile units 200. It is particularly beneficial 
when the ability to keep working on the data when it is 
offline is useful. For example, it could be applied to 
the field of computer games. In this embodiment, the web 
application server 100 or information servers 450 
maintain a central database relating to a multiplayer 
game: e.g. attributes of players, characters, simulated 
universes etc. in a manner associated with games such as 
Civilisation™, Age of Empires™, multi user dungeons, 
Pokemon™ etc. The web application server 100 with 
reference to the subscriber database 150 enables 
information relating to the game plus an associated 
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1 application in the form of a script customised to the 

2 particular mobile unit 200 to be delivered to individual 

3 players. The downloaded script then allows the player to 

4 continue play off-line, using, amending and adding to the 

5 stored information which is then synchronised 

6 periodically with the central database. 
7 

8 Further modifications and improvements can be made by one 

9 skilled within the art within the scope of the invention 
10 herein disclosed, 

11 



